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INTRODUCTION  /  OBJECTIVE 

The  objective  of  this  work 
was  to  develop  and 
demonstrate  a  means  for  the 
efficient  integration  of 
detailed  numerical  analysis 
into  the  design-optimization 
process.  In  this  initial 
phase  of  the  effort,  the  goal 
was  to  demonstrate  the 
tools  and  techniques  that 
allow  for  surface  definition 
and  grid  generation  to  be 
manipulated  inside  an 
optimization  loop  without 
user  intervention. 


Often,  substantial  effort  is 
required  to  set  up  a  detailed 
numerical  analysis.  The 
overall  goal  of  this  work 
was  to  allow  a  user  to 
leverage  this  effort  by 
providing  a  generic 

interface  to  advanced  tools,  such  as  optimization,  uncertainty  analysis,  trade  studies, 
parametric  modeling  and  the  like. 

The  following  example  illustrates  how  this  approach  impacts  the  design  process.  A  flow 
chart  of  the  typical  integration  of  numerical  analysis  into  the  design  process  is  shown  in 
Figure  1,  the  current  design  process.  In  this  scenario,  design  requirements  are  passed  to 
an  engineer/engineering  company  whose  job  it  is  to  design  a  part.  The  engineer 
generates  an  initial  concept  based  on  experience  and  available  first-order  tools.  The 
resulting  design  is  then  numerically  modeled  and  tested  against  the  design  requirements. 
If  the  design  meets  requirements,  the  job  is  done.  If  not,  or  if  the  design  is  for  a 
competition,  the  engineer  starts  making  trades  to  the  original  concept  in  an  attempt  to 
generate  a  design  that  meets  requirements.  In  general,  two  passes  through  the  detailed 
analysis  loop  are  all  that  time  and  budget  constraints  will  allow. 

Figure  2  shows  the  optimized-design  process.  In  this  scenario,  the  engineer  is  given 
and/or  generates  a  set  of  design  constraints.  This  information  is  used  to  determine  the 
design  space.  The  engineer  must  also  generate  a  set  of  Figures  of  Merit  (FOMs).  The 
objective  function  to  be  optimized  is  a  combination  of  the  FOMs.  The  relative  weight  of 
each  FOM  can,  for  example,  be  determined  by  system-level  sensitivity  studies.  The 
result  of  this  process  is  an  optimized  design  with  potentially  several  hundred  passes 


Good-Enough 

Solution 

Figure  1,  The  Current  Design  Process 
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through  the  detailed 
analysis  loop. 
Additionally,  a 
byproduct  of  the 
required  set-up  and 
mathematical  rigor  of 
the  optimization 
procedure  is  that  the 
process  has  documented 
the  resulting  solution. 


The  work  performed 
under  this  effort  can  be 
broken  up  into  three 
main  parts;  initial  set¬ 
up,  code  integration  and 
system  demonstration. 
The  initial  set-up 
includes  hardware 
selection  and 
installation  of  off-the- 
shelf  software.  The 
code  integration  effort 
was  primarily  software 
development;  scripts  were  written  to  link  components  of  the  analysis  together  and  code 
was  developed  to  generate  the  surfaces  for  the  analysis.  The  software  is  generally  in  the 
form  of  stand-alone  utilities  but  did,  in  certain  cases,  work  its  way  into  the  main  program 
architecture  as  an  option.  Finally,  the  system  was  tested  using  two  sample  cases,  a  jet  in 
cross  flow  and  a  shape  transition,  both  of  which  are  described  in  detail  later  in  the  text. 

INITIAL  SET-UP 

This  work  centered  on  putting  the  tools  in  place  and  operating  them  as  a  single  system  on 
the  Beowulf  cluster  which  was  purposely  built  by  Blue  Blanket  LLC  (BBLLC)  for  this 
task.  The  tools  used  are  VULCAN-CFD1,  DAKOTA2  and  GridPro4.  VULCAN-CFD 
and  DAKOTA  are  tools  developed  under  government  funding.  DAKOTA  is  freely 
available,  developed  under  the  GNU  public  license.  VULCAN-CFD  is  available  to  US 
citizens  through  NASA  Langley  Research  Center  (LaRC).  GridPro  is  a  commercial  tool, 
available  from  the  Program  Development  Company  (PDC). 

Computational  Cluster 

An  eight  processor  cluster  was  leased  from  BBLLC  with  an  initial  service  date  of  May 
15.  Although  the  hardware  for  the  compute  nodes  specified  (AMD  2800+  Barton  core, 
1GB  RAM,  gigabit  ethemet  network  connection)  was  available  within  the  initial  time 
frame,  the  high  capacity  (one  tera-byte)  hot-swappable  RAID  5  required  on  the  front-end 
was  not.  This  delayed  initial  service  date  by  two  weeks,  to  May  30.  Once  the  system 
came  on-line,  it  performed  well  throughout  the  seven  month  effort. 


Optimized  Solution 

Figure  2,  The  Desired  Design  Process 
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Software  Installation 

Once  this  cluster  was  in  place,  the  off-the-shelf  software  was  installed  and  tested. 

GridPro  and  DAKOTA  were  installed  from  binary  distributions  and  the  install  went  very 
smoothly.  Since  GridPro  is  a  commercial  product,  it  required  the  installation  of  a  license 
manager  and  a  license  key.  PDC  provided  no-cost  copy  of  GridPro  for  this  development 
work. 

Since  the  VULCAN  distribution  is  required  to  be  compiled  from  source,  the  installation 
was  a  little  more  involved  and  requires  a  FORTRAN  90  compiler.  The  Portland  Group 
(PGI)  compiler,  along  with  its  license  manager  and  key,  was  installed  on  the  cluster  and 
used  for  this  purpose.  To  compile  VULCAN,  the  MPI  libraries  had  to  be  re-built,  using 
the  PGI  compiler.  These  libraries  could  then  be  linked  into  the  VULCAN  executable. 
This  executable  was  turned  into  an  RPM  and  distributed  to  the  compute  nodes,  along 
with  a  required  PGI  library.  Installing  VULCAN  on  the  compute  nodes  allows  for  faster 
job  start-up  and  less  start-up  network  traffic  relative  to  launching  over  a  mounted 
network  drive.  The  fact  that  this  work  was  completed  in  a  timely  fashion  is  due  in  large 
part  to  the  help  of  Dr.  Robert  Baurle  at  NASA  LaRC  and  Mr.  Kevin  Fraze  at  BBLLC. 
Their  work  and  guidance  in  supporting  this  effort  is  greatly  appreciated. 

CODE  INTEGRATION 

Once  the  off-the-shelf  codes  were  installed  and  tested,  the  process  of  code  integration 
could  begin.  The  first  step  was  to  develop  a  strategy  of  how  the  optimization  process  will 
be  executed  on  the  cluster.  It  was  a  given  that  the  VULCAN-CFD  code  will  be  run  in 
parallel  via  jobs  being  submitted  to  the  queuing  system.  DAKOTA  can  be  run  in  either 
serial  or  parallel  mode.  For  the  purposes  of  this  work,  it  was  decided  to  run  DAKOTA  in 
serial  mode  on  the  front-end  (which  is  not  used  for  parallel  computing).  If  DAKOTA 
were  dealing  with  data  points  in  the  tens  of  thousands,  it  would  be  prudent  to  reconsider 
this  choice.  For  the  planned  cases,  where  the  number  of  function  evaluations  will  be  less 
than  100,  the  processing  time  required  by  DAKOTA  is  minimal,  so  running  on  the  front- 
end  seemed  to  be  the  appropriate  choice. 

GridPro  can  only  be  run  serially,  but  it  can  be  run  either  on  a  compute  node  or  on  the 
front-end.  It  was  decided  to  node  lock  a  license  to  the  front-end,  mainly  because,  from  a 
cost  perspective,  this  is  the  way  many  users  would  set  up  the  system.  Running  GridPro 
on  the  compute  nodes  requires  a  server  license  and  limits  number  of  concurrent  grid 
generation  jobs  to  the  number  of  licenses.  Running  GridPro  node  locked  to  a  computer 
allows  multiple  grid  generation  jobs  to  be  launched  simultaneously,  albeit  slowing  the 
solution.  Additionally,  this  choice  reduced  the  over  head  in  writing  the  scripts  that  run 
the  simulation. 


Cluster  Architecture 

The  cluster  uses  a  Red-Hat  based  distribution  called  ROCKS3,  developed  at  the 
University  of  California  San  Diego  (UCSD)  under  an  NSF  grant.  The  BBLLC  cluster 
uses  the  Torque/MAUI  combination  to  schedule  jobs  and  manage  resources  and  the 
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Ganglia  cluster  monitoring  tool.  This  combination  of  tools  worked  very  well,  resulting  in 
a  cluster  that  was  easy  to  use  and  monitor. 


GridPro 

Although  there  is  a  GUI  available,  GridPro  was  designed  from  the  ground  up  to  run  from 
a  command  line  interface,  as  well  as  through  the  GUI.  This  capability,  along  with  its 
particular  grid  generation  paradigm,  allows  it  to  be  used  in  a  “hands-off’  manner  via  the 
Topology  Input  Language  (TIL).  Documentation  for  features  can  be  found  in  the  GP 
User’s  Guide  and  Reference  Manual4. 

PDC  delivered  two  stand-alone  utilities  in  support  of  the  optimization  cases,  one  for  each 
case.  The  initial  utility  delivered  creates  a  “cap”  surface  at  the  intersection  of  two 
arbitrary  surfaces.  The  cap-surface  is  then  used  as  a  control  surface  during  the  grid 
generation  process.  The  second  utility  delivered  is  a  shape  transition  routine  allowing  for 
the  generation  of  a  transition  section  between  a  rectangular/oval/round  duct  to  a 
rectangular/oval/round  duct  of  different  shape  and/or  cross-sectional  area.  The  utilities 
are  detailed  in  each  of  the  sections  describing  the  work  where  they  were  used. 

VULCAN 

A  number  of  modifications  were  made  to  the  VULCAN-CFD  code  during  the  Phase  I 
effort.  These  modifications  can  be  categorized  as: 

•  Integration  with  GridPro. 

•  Integration  with  DAKOTA 

•  Improve  load  balancing 

•  Implementation  of  a  new  boundary  condition 

Integration  with  GridPro 

The  GridPro  code  produces  C(0)  multi-block  structured  grids.  The  design  of  GridPro  is 
such  that  the  grids  it  produces  can  consist  of  up  to  hundreds  and  occasionally  even 
thousands  of  blocks.  This  plethora  of  blocks,  which  are  useful  in  capturing  geometric 
features  and  load  balancing,  makes  manually  specifying  the  boundary  conditions  and 
block-to-block  connectivity  of  these  grids  utterly  impractical.  However,  GridPro  provides 
a  method  to  graphically  specify  the  boundary  conditions  by  associating  them  with 
surfaces  as  well  as  automatically  keeping  track  of  and  recording  the  block-to-block 
connectivity  as  the  grid  topology  is  generated.  The  grid  connectivity  and  boundary 
conditions  can  then  be  exported  into  a  formatted  text  file.  The  file,  which  is  unique  to 
GridPro,  required  that  a  translator  was  written  that  converts  the  information  in  the 
GridPro  file  into  a  form  readable  by  the  VULCAN-CFD  code  as  well  as  the  VULCAN- 
CFD  code  input  file  graphical  user  interface. 
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Improve  load  balancing 

The  large  number  of  blocks  produced  by  the  GridPro  code  could  also  cause  difficulties 
for  the  native  VULCAN-CFD  code  load  balancing  algorithm  that  could  result  in  poor 
performance  on  multi-processor  platforms.  These  difficulties  are  due  to  the  native 
algorithm  not  considering  communication  overhead  when  distributing  the  blocks  among 
the  available  processors.  This  algorithmic  deficiency  could  and  has  caused  blocks  to  be 
distributed  such  that  there  would  be  much  more  inter-processor  communication  than  need 
be.  This  could  produce  poor  scaling  and  performance  on  parallel  machines,  particularly 
on  machines  with  high  inter-processor  latency.  To  alleviate  this  deficiency  a  strategy  in 
use  by  the  unstructured  grid  community  was  adapted  for  use  with  structured  multi-block 
grids.  The  graph  partitioning  code  METIS  developed  at  the  University  of  Minnesota  has 
been  used  to  partition  the  multi-block  grid  in  a  manner  similar  to  how  unstructured  grid 
are  partitioned  using  METIS.  The  METIS  code  requires  a  graph  of  the  computational  grid 
to  be  partitioned  where  the  graph  is  made  up  of  vertices  and  edges.  For  unstructured  grids 
there  is  a  one-to-one  correspondence  between  the  graph  vertices  and  the  unstructured  grid 
nodes  and  between  the  graph  edges  and  the  unstructured  grid  lines.  However,  the 
correspondence  between  the  graph  entities  and  multi-block  structured  grids  is  a  little 
more  abstract.  Fortunately,  it  is  possible  to  define  a  correspondence  between  the  graph 
vertices  and  a  structured  grid  block  and  between  the  graph  edges  and  the  structured  grid 
block-to-block  connectivity.  This  correspondence  was  exploited  to  develop  a  structured 
grid  graphing  subroutine  that  was  implemented  into  the  VULCAN-CFD  code  and  the 
METIS  code  was  integrated  into  the  VULCAN-CFD  code  scripting  to  allow  the  code  to 
be  automatically  run  to  produce  graphs  of  multi-block  structured  grids,  partition  the 
graph,  and  use  the  resulting  graph  partition  file  to  distribute  the  grids  over  the  processors 
so  as  to  simultaneously  balance  the  computational  load  and  minimize  the  communication 
overhead. 

Integration  with  DAKOTA 

In  order  to  stream  line  the  optimization  analysis  process,  it  was  decided  to  modify  the 
VULCAN-CFD  to  process  the  required  Figure  of  Merit  (FOM)  data  from  the  simulation 
output.  These  data  were  then  read  from  the  output  fdes  and  passed  back  to  DAKOTA 
which  are  then  used  to  drive  the  optimization  process.  A  number  of  FOMs  already 
existed  in  the  VULCAN-CFD  code,  most  of  which  related  to  integrated  forces  and 
moments.  The  existing  surface  integration  routines  output  data  on  an  iteration-by- 
iteration  basis.  Several  new  parameters  were  added  to  the  VULCAN-CFD  code  to 
support  the  fuel  injector  and  the  transition  duct  demonstration  cases.  In  addition  the  FOM 
surface  integration  logic  was  extended  from  the  original  post-processing  approach  to 
include  a  real  time  approach.  This  was  done  to  provide  a  real  time  output  of  the  FOM  to  a 
separate  file  to  simplify  the  process  of  interfacing  VULCAN-CFD  with  IDEA-NL  and  to 
allow  the  IDEA-NL  a  way  to  monitor  the  CFD  simulation  in  real  time  so  that 
“converged”  jobs  could  be  detected  and  stopped  and  “divergent”  jobs  or  jobs  with  poor 
FOM  convergence  could  be  detected  and  culled.  The  following  FOMs  are  currently 
available  in  the  VULCAN-CFD  code  (new  additions  in  italics): 

•  Forces  and  moments 

•  Mass  flow  error 
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•  Total  heat  flux 

•  Fuel  penetration  height 

•  Fuel  mixing  efficiency 

•  Mass  averaged  total  pressure  loss 

Near  real  time  plotting  of  the  various  output  parameters  was  also  added  to  the  VULCAN- 
CFD  GUI  using  Tecplot  layout  files  and  scripts.  Figure  3  presents  hydrogen  (H2)  mass 
fraction  contour  for  the  sonic  normal  injection  of  hydrogen  into  a  supersonic  crossflow  of 
air  that  was  used  to  test  the  real  time  output  of  the  parameters.  Figure  4  presents  plots  of 
the  convergence  and  figures  of  merit,  including  the  fuel  penetration  height  and  mixing 
efficiency,  added  during  the  Phase  I  effort,  for  the  aforementioned  fuel  injection 
demonstration  case. 


Figure  3,  Contours  of  Hydrogen  Mass  Fraction  on  the  Centerline  and  Outflow 

Planes 
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Figure  4,  Real-Time  Convergence  and  Various  Parameters  Including  Fuel  Mixing 

Efficiency  and  Penetration  Height 


Boundary  Condition  Modification 

One  final  modification  was  made  to  the  VULCAN-CFD  code  to  streamline  setting  up  the 
analysis  of  the  fuel  injector  demonstration  case.  The  existing  specified  mass  flow/unit 
area  boundary  condition  in  VULCAN-CFD  code  was  modified  to  allow  specification  of 
both  the  mass  flow/unit  area  and  the  flow  cross  sectional  area  of  the  “baseline”  grid.  This 
was  done  to  allow  the  total  mass  flow  to  be  held  constant  as  the  cross-sectional  area 
varied  from  geometry  to  geometry  during  the  optimization  process.  This  could  have  been 
done,  with  considerable  effort,  by  adding  a  constraints,  calculating  cross  sectional  areas 
and  modifying  the  VULCAN-CFD  input  file  each  system-level  iteration.  Adding  the 
capability  directly  to  VULCAN-CFD  code  was  more  efficient  to  implement,  a  benefit  of 
having  the  source  code  available. 

DAKOTA 

As  part  of  its  distribution,  DAKOTA  provides  a  set  of  utilities  to  integrate  various  pieces 
of  software  via  input/output  files.  This  capability,  largely  provided  by  a  suite  of  PERL 
scripts,  was  used  during  the  phase  I  effort.  The  work-horse  script  is  called  dprepro.prl. 

It  processes  a  file  by  searching  for  user-defined  place  holders  and  replacing  them  with 
user  supplied  data.  The  syntax  is  shown  in  Appendix  1  .A,  a  listing  of  a  driver  script 
where  the  DAKOTA  pre-processor  utility  was  used. 
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TOOL  DEMONSTRATION 
FUEL  INJECTOR  CASE 
Baseline 

Starting  an  optimized  analysis  was  very  much  similar  to  starting  any  other  CFD  analysis. 
A  computational  domain  was  defined  and  the  appropriate  type  of  analysis  to  be  run 
identified.  In  this  case,  the  computational  domain  was  a  one  inch  cube  with  a  round  tube 
0.080  inches  in  diameter  intersecting  the  cube  at  90  degrees.  This  is  shown  Figure  5, 
Grid  for  Fuel  Injector  Study.  The  grid  employs  a  wall  spacing  of  0.003  inches  and  a 
stretching  factor  of  1.1,  so  it  is  suitable  for  viscous  calculations.  This  resulted  in  a  total 
of  190,260  cells  in  the  grid. 


Figure  5,  Grid  for  Fuel  Injector  Study 


•  lxlxl  Cube 

•  0.080  Dia  hole 

•  Total  Grid  Points  -  190,260  cells 

•  Wall  spacing  0.003  spacing,  stretch  =1.1 


The  purpose  of  this  work  is  to  demonstrate  the  tool  and  methodology,  not  to  develop  a 
fuel  injector  design.  This  fact,  in  combination  with  the  limited  computational  resources, 
drove  our  choice  of  modeling  detail.  For  the  fuel  injector  case,  jet  penetration  was 
chosen  as  the  primary  FOM.  Other  FOMs  considered  were  not  used  for  various  reasons. 
For  instance,  a  mixing  efficiency  would  require  a  longer  duct  to  see  significant 
differences  and  combustion  efficiency  would  add  the  requirement  of  modeling 
chemically  reacting  flow.  Choosing  penetration  as  our  FOM  simplified  the  required 
analysis,  allowing  the  simulations  to  be  run  adiabatic  with  thermally  perfect,  frozen 
chemistry.  The  boundary  condition  types  set  on  the  simulation  are  shown  in  Figure  6. 
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Figure  6,  Boundary  Condition  Specification  for  Fuel  Injector  Study 

The  boundaries  on  three  sides  of  the  cube  were  set  to  symmetry;  the  outflow  boundary  is 
set  to  extrapolate;  the  wall  boundaries  set  to  adiabatic  with  wall  functions;  and,  the  inflow 
boundaries,  both  the  main  flow  and  fuel  injector,  were  set  to  the  fixed  BC.  Setting  the 
fuel  injector  BC  to  be  fixed  instead  of  subsonic  inflow  was  done  to  facilitate  the  initial 
optimization  testing  on  a  local  workstation.  This  is  further  described  in  a  section  to 
follow.  The  fixed  main  inflow  was  set  to  be  air  incoming  at  Mach  2  flow.  A  VULCAN- 
CFD  input  file,  which  is  located  in  the  Appendix  1  .B,  was  created  for  this  case  and  the 
baseline  fuel  injector  case  was  run. 

Once  the  baseline  simulation  was  complete,  the  optimization  runs  were  started.  The 
initial  optimization  runs  were  performed  using  only  VULCAN-CFD  and  DAKOTA  on  a 
local  workstation  while  the  cluster  was  coming  up.  This  was  done  to  get  some 
experience  setting  up  a  DAKOTA  input  file  and  develop  a  feel  for  how  DAKOTA  works. 
DAKOTA  was  given  a  fuel  density  range  and  set-up  to  maximize  the  fuel  flow  rate  using 
the  fuel  density  as  the  control  variable.  A  DAKOTA  driver  script  was  written  to  modify 
a  special  VULCAN-CFD  input  template  file  where  the  tag  $DENS$  was  inserted  in  place 
of  the  values  of  the  fuel  density  in  the  baseline  input  file.  The  script  reads  in  the  template 
input  file,  searches  for  the  tag  and  replaces  it  with  the  value  of  density  determined 
supplied  to  the  script  by  DAKOTA.  The  script  then  parsed  the  VULCAN  output  file  for 
the  flow  rate  at  the  fuel  injector  inflow  boundary  which  was  then  passed  to  DAKOTA  as 
the  value  to  optimize.  This  was  the  aforementioned  motivation  for  running  with  the 
FIXED  boundary  on  the  fuel  injector.  Since  the  boundary  condition  under  optimization 
is  being  set  directly,  the  simulations  only  need  to  run  a  single  iteration  before  they  can  be 
processed  for  the  FOM.  For  subsequent  runs  where  the  figures  of  merit  require  a 
converged  solution,  the  BC  for  the  fuel  injector  is  switched  to  SUB  IN. 
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As  expected,  DAKOTA  chose  the  maximum  total  density  as  the  value  of  the  independent 
variable  that  maximized  the  injector  flow  rate.  No  geometry  changes  within  the 
optimization  loop  were  attempted  for  this  initial  work. 


The  maximum  density  case  was  then  run  to  convergence  for  use  as  the  baseline  case. 
This  was  an  oversight  as  the  equivalence  ratio  for  this  case  was  a  little  greater  than  five. 
This  did  lead  to  excellent  penetration  and  plume  growth,  as  can  be  seen  in  Figure  7.  The 
plume  is  penetrated  about  half  an  inch  and  has  spread  to  approximately  0.4  inches  in 
diameter.  Unfortunately,  the  high  mass  flow  being  injected  caused  the  flow  to  shock 
down  to  subsonic  in  a  large  portion  of  the  computational  domain.  This  operation  serves 
to  highlight  the  fact  that  care  must  be  given  when  setting  up  the  domain  to  be  optimized 
so  that  100  of  cpu-months  are  not  spent  to  determine  a  solution  which  is  not  feasible  for 
the  operational  system. 


Figure  8,  Mach  Number  at  the  Boundaries  of  the  Computation  Domain  for  High  Phi  Case 
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The  flow  rate  was  then  dropped  to  correspond  to  a  more  reasonable  phi  of  0.5.  This  was 
used  as  the  baseline  case  for  the  fuel  injector  optimization 

GEOMETRY  and  GRID  GENERATION 

For  the  most  part,  the  geometry  required  to  generate  the  grid  can  be  created  internally  in 
GridPro,  making  it  convenient  for  the  man-out-of-loop  optimization.  This  is  true  of  the 
cube  (a  set  of  6  planes),  the  fuel  injector  tube  (a  super-ellipse)  and  the  plane  that  defines 
the  inflow  boundary  of  the  fuel  injector  tube.  However,  in  order  to  generate  an  accurate 
grid,  an  internal  “cap”  surface  must  be  created.  This  surface,  which  is  created  from  the 
intersection  of  the  fuel  injector  tube  and  plane,  is  shown  in  Figure  9.  The  purpose  of  the 
surface  is  to  ensure  the  grid  is  held  tightly  (sharp  comers)  to  the  intersection  of  the  fuel 
injector  tube  and  the  plane.  This  cap  surface  was  only  able  to  be  generated  through  the 
GridPro  GUI. 


While  the  cluster  was  coming  up,  GridPro  reworked  the  utility  so  that  it  could  be  called 
from  the  command  line.  The  utility  was  completed  and  delivered  during  the  initial  two 
month  period.  The  utility  takes  as  input  the  coefficients  and  exponents  of  the  super¬ 
ellipse  for  the  fuel  injector  definition.  The  intersecting  plane  is  defined  by  inputting  a 
point  on  the  plane  and  the  normal  to  the  plane.  The  final  input  to  the  utility  is  the  name 
of  the  output  file  the  surface  is  written  to. 


For  reference,  the  equation  of  a  super-ellipse  is  shown  in  Equation  1. 


f(x,y,z ) 


Equation  1 


In  order  to  ran  the  optimization,  u,  v  and  EXP  were  chosen  as  the  design  variables.  The 
intersecting  plane  was  defined  to  be  normal  to  the  y-direction  and  pass  through  the  origin. 
The  y  coefficient  is  set  to  be  very  large  compared  to  the  x  and  z  coefficients,  which  yields 
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the  desired  tube-like  shape.  Varying  the  x  and  z  coefficients  morphs  the  cross  section  of 
the  fuel  injector  from  a  circle  to  an  ellipse.  Varying  the  exponent  morphs  the  cross 
section  of  the  fuel  injector  from  a  circle  to  a  square.  Other  forms  of  the  super-ellipse 
equation  allow  for  a  wider  range  of  possible  configurations.  These  cases  would, 
however,  require  a  more  sophisticated  topology. 

Table  1,  Values  of  the  Design  Variables  Chosen  for  Optimization 


u 

w 

EXP 

Nominal 

20 

20 

2 

Maximum 

40 

40 

2 

Minimum 

10 

10 

15 

The  value  ranges  for  the  design  variables  are  shown  in  Table  1.  No  effort  was  made  to 
constrain  the  combinations  of  variables  to  conserve  area. 


RUN  SCRIPT 

Once  the  utility  was  complete,  a  run  script  was  created  that  took  input  from  DAKOTA, 
generated  a  cap  surface  and  matching  fuel  injector  tube,  then  a  computational  grid.  The 
simulation  is  then  run  on  the  grid  and  the  FOMs  passed  back  to  DAKOTA.  The  run 
script  is  discussed  in  detail  in  Appendix  l.C.  The  results  of  the  analysis  are  discussed 
below. 


RESULTS 

As  described  above,  this  work  allowed  for  the  fuel  injector  cross  section  area  to  very 
from  a  circle  through  an  oval  to  a  square.  The  results  of  the  analysis,  after  58  iterations, 
are  shown  below  in  Figure  10. 
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Figure  10,  Results  of  the  Fuel  Injector  Cross  Section  Optimization 


Note  that  for  approximately  thirty  iterations,  the  penetration  height  (the  objective 
function)  bounces  around  a  minimum.  Investigation  revealed  that  the  optimization  was 
run  to  minimize  the  penetration  height,  as  opposed  to  maximize  it  as  was  the  stated  goal. 
Further  investigation  showed  the  penetration  height  was  a  very  strong  function  of  mass 
flow  and  the  solution  bounced  around  the  minimum  area.  The  available  VULCAN-CFD 
boundary  conditions  only  allowed  the  mass  flow  per  unit  area  to  be  set,  not  the  absolute 
mass  flow.  While  this  could  be  overcome  with  significant  effort  using  scripts  to  calculate 
areas  and  perform  density  ratios,  the  far  easier  solution  was  to  add  the  capability  into  the 
VULCAN-CFD  code.  This  was  accomplished  by  modifying  the  SUBIN  boundary 
condition  as  described  in  the  Boundary  Condition  Modification  section  above. 

The  decision  was  made  to  begin  the  shape  transition  work  while  the  new  boundary 
condition  was  being  implemented.  Unfortunately,  the  remaining  time  was  used  working 
with  the  shape  transition  analysis,  so  fuel  injector  the  analysis  was  not  re-run  with  the 
constant  mass  flow  boundary  condition. 


Shape  Transition 

In  order  to  demonstrate  the  optimization  of  a  shape  transition,  a  generic  transition,  from  a 
rectangle  to  a  circle,  was  chosen.  The  rectangle,  which  is  the  inflow  boundary,  has  an 
aspect  ratio  of  four-to-one.  The  circle  has  an  area  equal  to  95%  of  the  area  of  the 
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Figure  11,  Schematic  of  Shape  Transition 
with  Control  Fixed  Points  Shown 


rectangle.  For  a  rectangle  with  sides  of  1  inch 
and  4  inches,  the  radius  of  the  circle  is  1 . 1 
inches.  The  length  of  the  transition  section  was 
set  at  one  diameter,  or  2.2  inches.  As  shown  in 
Figure  11,  eight  control  points  were  located 
around  both  the  rectangular  and  circular  cross 
sections.  These  points  are  frozen  in  the  analysis, 
freezing  the  shape  of  the  boundaries.  These 
points,  along  with  a  ring  of  control  points  located 
mid-span,  were  used  to  control  the  geometry  of 
the  shape  transition  duct  during  the  optimization. 


Baseline  Case 

In  order  to  generate  a  representative  baseline,  a  surface  was  generated  in  a  similar  manner 
to  what  is  currently  done  in  industry.  That  is,  to  generate  a  lofted  surface  using  a 
commercial  CAD  package.  In  this 
transition  duct.  This  duct,  after 
being  converted  to  the  STL  fde 
format,  is  shown  in  Figure  12. 

Care  must  be  taken  when  doing 
the  file  conversion  as  to  capture 
the  contour  of  the  surface  being 
manipulated. 

Once  the  surface  is  converted  to 
an  STL  file  format,  it  can  be  read 
into  GridPro  as  a  surface.  Two 
additional  grid  control  surfaces, 
planes  to  cap  the  inflow 
(rectangular)  and  outflow  (circular) 

Grid  Generation 

The  topology  laid  out  for  the  grid  generation,  along  with  the  resulting  grid,  is  shown  in 
Figure  13.  This  topology  generates  an  OH  grid.  While  this  grid  works  well  for  circular 
cross  sections,  additional  steps  must  be  taken  to  ensure  the  sharp  comers  in  the  rectangles 
are  properly  modeled.  It  was  decided  that,  for  the  purpose  of  demonstrating  the  tool,  the 
added  complexity  of  capturing  the  sharp  comers  was  not  required.  The  affected  areas  are 
highlighted  in  the  left  hand  picture  of  Figure  13. 


case,  Solid  Edge  was  used  to  generate  the  lofted 


Figure  12.  Baseline  Lofted  Surface  Converted  to  an  STL. 
boundaries,  are  generated  within  GridPro. 
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Figure  13.  Topology  and  Grid  for  Baseline  Shape  Transition  Case 

The  topology  is  defined  to  be  general  enough  to  handle  the  changes  as  the  shape 
transition  surface  is  updated,  and  generate  an  appropriate  grid.  The  grid  has  five  zones. 
Each  zone  is  broken  into  48x48x48  cells  for  a  total  of  552,960  cells.  The  simulations 
were  run  frictionless,  so  no  particular  wall  clustering  was  specified. 

Baseline  CFD  Results 

In  addition  to  the  decision  to  assume  inviscid  flow,  the  simulation  was  run  assuming 
perfect  gas.  In  the  actual  design  process,  as  the  design  is  refined  and  the  design  space 
narrows,  more  detail  can  be  added  to  the  models  as  required. 

A  uniform  inflow  profile  was  used,  as  was  an  extrapolate  outflow  boundary  condition. 
Table  2  lists  the  aero-thermal  values  specified  at  the  inflow  boundary. 


Table  2.  Uniform  Inflow  Boundary  Condition  Specification 


Mach  Number 

Temperature 

Pressure 

Gamma 

Gas  Constant 

--- 

K 

Pa 

--- 

J /  (kg  K) 

2.5 

300 

50000 

1.4 

287 

The  inflow  boundary  conditions  were  chosen  in  part  to  ensure  supersonic  flow  was 
maintained  at  the  outflow  boundary  so  that  the  boundary  condition  specified  remained 
well-posed.  The  inflow  velocity  vector  was  aligned  with  the  x-direction. 

The  wall  pressure  profile  for  the  top  and  side  of  the  duct  are  shown  in  Figure’s  14  and  17. 
The  shape  of  the  compression  wave  is  evident  in  Figure  14,  the  top  view.  The  waves 
generated  by  the  side  wall  compression  coalesce  just  upstream  of  the  exit  plane.  The 
profile  at  the  exit  plane  is  indicative  of  a  wave  pattern  that  would  continue  to  reflect 
down  a  duct. 
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Figure  14,  Uniform  Inflow  Wall 
Pressure  Contour  Plot  -  Baseline 


Figure  15,  Uniform  Inflow  Mach 
Number  Contour  Plot  -  Baseline 
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Figure  16,  Uniform  Inflow  Side-Wall  Figure  17,  Uniform  Inflow  Mach  Number 

Pressure  Contour  Plot  -  Baseline  Contour  Plot  -  Baseline 
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The  total  pressure  loss  for  this  case  was  calculated  to  be  40.32%.  Obviously  this  is  a 
large  number  and  no  real  system  could  tolerate  such  a  loss  in  total  pressure  and  stay 
operational.  This  is,  however,  an  excellent  candidate  for  optimization! 

Surface  Generation 


A  utility  called  subdivision  was  used  to  generate  the  surfaces  for  the  analysis. 

Subdivision  allows  the  user  to  define  a  set  of  control  points  through  which  the  surface 

passes.  Additionally,  the  user  can 
control  the  normal  to  the  surface  at  those 
points.  The  user  communicates  with  the 
utility  via  an  input  file. 

A  comparison  of  the  baseline  lofted 
surface  and  the  surface  generated  by 
subdivision  is  shown  in  Figure  16. 

The  subdivision  surface  was  generated 
by  defining  two  rings  of  eight  control 
points  at  the  entrance  (the  rectangular 
section)  and  exit  (the  round  section)  of 
the  shape  transition.  These  points  were 
then  input  into  subdivision  which 
generated  a  surface  passing  through  the 
points.  These  control  points  remained 
fixed  during  the  optimization  process. 
Once  the  subdivision  surface  was 
generated,  a  third  set  of  eight  control 
points  was  defined  mid-span.  Each  of  these  control  points  are  on  the  surface  and  between 
the  corresponding  control  points  on  the  inflow  and  outflow  boundaries.  This  is  shown 
graphically  in  Figure  17.  Since  these  points  were  selected  graphically,  they  do  not  lie 
exactly  on  the  surface,  nor  are  they  necessarily  symmetric.  This  will  not  affect  the 
demonstration  of  the  tool  and  should  not  affect  the  quality  of  the  answer. 


Figure  16.  Comparison  of  Lofted  Shape  Transition 
to  Transition  Generated  from  the  Subdivision 
Surface  Generation  Utilitv 
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Figure  17.  Surface  with  Control  Points  to  Perform  Optimization 


Optimization  Set-Up 

In  order  to  set  up  the  optimization,  it  is  necessary  to  have  a  good  understanding  of  two 
things,  the  inputs  to  the  analytical  model  with  at  least  a  basic  understanding  of  how  the 
inputs  will  affect  the  results  and  how  to  process  the  results  of  the  analysis  to  arrive  at  an 
objective  function  that  is  to  be  optimized. 

As  described  earlier,  the  inputs  to  subdivision  are  the  control  points  that  the  surface 
passes  through  and  the  normal  to  the  surface  at  those  points.  Each  of  the  control  points  in 
Figure  17  has  four  degrees  of  freedom  (DOF),  three  spatial  and  the  surface  normal  at 
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each  point.  For  a  ring  of  eight  control 
points,  this  results  in  potentially  32 
independent  variables  to  be  optimized.  This 
is  a  large  number  of  combinations  to  be 
investigated.  Initially,  the  optimization  will 
be  limited  to  16  DOF’s,  two  for  each  mid¬ 
span  control  point.  The  control  points  will 
be  constrained  to  stay  mid-span  and  the 
normal  to  each  point  will  not  be  set  a-priori. 
The  initial  conditions,  along  with  the 
bounds  for  each  point,  are  shown  in  Figure 
18. 


Note  in  the  figure  that  the  control  points  at 
the  Z  ~=  0  line  have  the  greatest  allowable 
motion,  followed  by  the  “comer”  points.  The  Y  ~=  0  points  have  the  tightest  control  on 
their  movement.  This  is  an  artifact  of  the  way  the  mid-span  control  points  were  chosen 
(inline  with  the  control  points  located  on  the  inflow  and  outflow  boundaries)  along  with 
the  desire  not  to  allow  multiple  points-of-inflection  between  any  three  control  points.  In 
practice,  this  requires  the  bottom  control  point  always  be  below  the  adjacent  “comer” 
points.  Like  wise,  the  top  and  side  points  should  always  be  out-board  of  their  adjacent 
“comer”  points.  In  future  set-ups,  the  design  space  can  be  more  open  with  point-of- 
inflection  type  requirements  accomplished  with  constraints. 

The  second  part  of  setting  up  the  optimization  case  was  processing  a  figure  of  merit 
(FOM)  to  be  either  minimized  or  maximized.  The  FOM  chosen  for  this  work  is  to 
minimize  the  total  pressure  loss  across  the  shape  transition.  Recall  that  the  area  of  the 
shape  transition  section  decreases  five  percent  causing  the  supersonic  flow  to  compress. 
There  is  an  inherent  loss  in  total  pressure  across  compression  waves  so  an  obvious  choice 
in  performing  the  optimization  is  to  minimize  the  total  pressure  loss  across  the  shape 
transition.  In  order  to  ensure  the  FOM  has  stabilized,  a  mass  averaged  total  pressure  loss 
calculation  was  added  to  the  VULCAN  output.  As  described  earlier,  the  FOM  can  be 
calculated  a  variety  of  different  ways  and  does  not  require  modification  of  the  source 
code  of  the  solver.  This  does,  however  demonstrate  the  significant  utility  of  having  the 
source  code  available. 

The  optimization  routine  used  comes  from  the  SGOPT  (Stochastic  Global  OPTimization) 
library,  which  is  included  with  the  base  DAKOTA  install.  This  is  a  non-gradient  based 
library  of  methods  that  include  both  local  (Solis-Wets  and  pattern  search)  and  global 
(genetic  patter  search,  evolutionary  pattern  search  and  stratified  Monte  Carlo)  algorithms. 
For  this  work,  the  pattern  search  scheme  was  chosen  and  run  over  50  iterations. 
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Figure  18.  Mid-Span  Control  Points  and  Their 
Associated  Range  of  Motion 
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Optimization  Results 

Over  three  days,  there  were  50 
geometries  analyzed,  with  50 
different  grids,  without  human 
intervention.  New  surfaces  were 
generated  based  on  the  ring  of 
control  points  whose  positions 
were  determined  by  the 
optimizer.  A  plot  of  the  control 
point  locations  for  each  of  the 
iterations  is  shown  in  Figure  19. 
The  locations  of  some  of  the 
control  points  did  not  vary  much 
at  all  while  others  were  more 
distributed  about  the  design 
space.  This  is  evidence  that  50 
iterations  is  not  enough  to  sample 
the  design  space  of  16 
independent  variables. 

Even  though  the  analysis  has  not  thoroughly  probed  the  design  space,  it  is  still  possible  to 
see  if  the  there  has  been  any  improvement  in  total  pressure  loss.  Figure  20  shows  the 
percent  decrease  in  total  pressure  loss  on  an  iteration-by-iteration  basis.  As  can  be  seen, 
there  are  many  trials  where  there  is  significant  improvement  of  the  lofted  surface. 

Sixteen  of  the  50  runs  had  reduced  the  total  pressure  loss  by  at  least  5  %.  The  best  design 
generated  to  date  is  iteration  number  20  which  has  a  total  pressure  loss  of  37.2  %,  a  7.7% 
reduction  in  total  pressure  loss. 

Surprisingly,  only  three  of  the 
simulations  showed  an  increase  in 
total  pressure  loss.  These  runs, 
combined  with  the  three  runs  that 
showed  less  than  0.5% 
improvement,  accounted  for  only 
12  %  of  the  iterations.  This  is  due 
to  in  part  to  the  pattern  search 
scheme  looking  for  a  local,  verses 
a  global,  optimum.  Overall,  a 
7.7%  reduction  in  total  pressure 
loss  is  a  promising  result  for  so  few  iterations. 


Figure  20.  Percent  Decrease  in  Total  Pressure  Loss  on  an 
Iteration  By  Iteration  Basis 
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Figure  19.  Scatter  Plot  of  Control  Point  Location  for  the  50 
Optimization  Iterations 
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The  comparison  of  the  iteration  20  surface  and  the  baseline  surface  is  shown  in  Figure  21. 

It  is  important  to  note  that  flow  in  this  picture  is 
from  right-to-left.  The  aqua  surface  is  the 
baseline  and  the  blue  surface  is  the  surface  from 
iteration  number  20.  Note  that  the  baseline 
surface  is  not  symmetric.  The  lower  surface  is 
pulled  up  into  the  flow  path  relative  to  the 
baseline  and  the  upper  surface  is  slightly  above 
the  baseline. 


If  the  optimization  case  were  allowed  to 
continue  to  run,  it  is  believed  that,  for  this  case, 
a  symmetric  solution  would  result. 
Unfortunately,  time  and  computational 
constraints  prohibited  this  from  being  done. 
The  reason  that  symmetry  was  not  exploited  is 
found  in  the  follow  on  work  which  used  inflow 
profiles  that  were  not  necessarily  symmetric. 
This  work  is  briefly  described  in  the  following 


Figure  21.  Comparison  of  Baseline  Lofted 
Surface  and  the  Iteration  20  "Best"  Surface 
Generated  by  the  Optimizer 

section. 


The  simulation  results  from  twentieth  iteration  are  shown  below.  In  Figure  22  you  can 
see  the  asymmetry  in  the  wall  pressure  distribution  viewed  from  the  top. 
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Figure  22.  Top  Wall  Pressure  Profiles  for  the  Baseline  and  Iteration-Twenty  Cases 
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Figure  23.  Exit  Plane  Pressure  Contours  for  the  Baseline  Case  and  Iteration-Twenty  Cases 
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Figure  24.  Comparison  of  Outflow  Mach  Number  for  the  Baseline  and  Iteration-Twenty  Cases 


The  flow  exiting  the  shape  transition  from  the  optimizer  is  much  more  distorted  than  the 
baseline  case.  Additionally,  the  minimum  Mach  number  at  the  exit  plane  is  lower  in  case 
twenty  (MnMiN  =1.05)  than  the  baseline  simulation  (MnMiN  =  1.2).  This  causes  some 
concern  that,  although  the  residual  dropped  four  orders  of  magnitude  and  was  well 
behaved,  the  exit  boundary  condition  may  not  be  well  posed  for  all  of  the  solutions  and 
should  be  checked. 


The  convergence  history,  conservation  of  mass  and  total  pressure  loss  parameters  are  all 
shown  in  Figure  25.  The  percent  error  in  mass  flow  is  driven  to  zero  and  the  total 
pressure  loss  calculation  is  steady. 

Therefore,  even  though  the  residual  is 
still  dropping,  the  FOM  is  steady  and  the 
solution  is  converged  enough  to  be 
useful. 

When  assessing  the  solution  it  is 
important  to  keep  in  mind  that  the 
simulation  is  frictionless  and  the  flow  can 
turn  along  wall  angles  that  are  unrealistic. 

This  behavior  will  allow  for  geometries 
that  would  normally  separate  to 
essentially  not  be  penalized.  If  this  were 
for  a  design  to  be  built,  the  simulations 
would  be  run  viscous. 

Figure  25.  Clean  Case  20  Convergence  History 


Four  Inflow  Profiles 

An  additional  benefit  of  using  the  OH-grid  methodology  was  that  it  provided  the  ability 
to  rapidly  set  different  inflow  profiles.  There  were  four  inflow  profiles  used  when 
investigating  the  shape  transition  optimization  scheme.  These  profiles  include  a  clean 
(NO  DIST)  inflow  profile  and  three  distorted  profiles;  circumferential  (CIRC),  Outer 
Diameter  (OD)  and  Inner  Diameter  (ID).  For  the  purposes  of  this  work,  distortion  is 
defined  as  a  mismatch  in  total  pressure.  OD  distortion  is  defined  to  be  a  total  pressure 
deficit  near  the  wall  or  the  OD  of  the  duct  while  ID  distortion  is  lower  total  pressure  near 
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the  core  or  the  ID  of  the  duct.  CIRC  distortion  is  defined  to  be  a  mismatch  in  total 
pressure  from  one  side  of  the  duct  to  the  other. 

To  create  the  distortion,  the  velocity  was  increased  and  decreased  by  10%  and  the  static 
density  was  altered  by  10%  in  the  opposite  direction  of  the  velocity  change.  The  static 
temperature  was  held  constant.  This  approach  conserved  mass  and  momentum  but 
created  a  mismatch  in  velocity,  static  and  total  pressure.  The  value  of  each  of  these 
quantities  is  shown  below  in  Table  3. 


Table  3,  Thermodynamic  Inputs  for  Clean  and  Distorted  Inflow  USed  During  the  Shape  Transition 

Demonstration 


Static  density 

Axial  velocity 

Static  Temperature 

Total  Pressure 

Low  Velocity  Flow 

0.38327526 

1008.3 

500.0 

635972 

Nominal  Flow 

0.348432 

1120 . 5 

500.0 

854297 

Hi  Velocity  Flow 

0.31358885 

1232.7 

500.0 

1131316 

Baseline  Distortion  Cases 

The  Mach  number  profiles  for  each  of  the  inflows  are  shown  below  in  Figure  26.  The 
solutions  were  generated  using  the  baseline  lofted  surface.  It  is  interesting  to  see  how  the 
distorted  profiles  influence  the  shock  structure.  The  OD  distortion  pulls  the  pressure 
wave  intersection  back  in  the  duct  while  the  ID  distortion  pushes  the  intersection  forward 
in  the  duct.  The  circumferential  distortion  causes  the  pressure  waves  to  intersect  in  the 
side  of  the  duct  with  the  higher  initial  velocity. 


Figure  26.  Four  Inflow  Mach  Number  Profiles  Used  for  Shane  Transition 
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Figure  27,  Total  Pressure  Profiles  at  the  Exit  of  the  Baseline  Shape  Transition 


The  total  pressure  pattern  at  the  exit  of  the  duct  for  each  distorted  inflow  profile  is  shown 
in  Figure  27.  The  duct  with  no  distortion  has  the  most  uniform  total  pressure  profile  at 
the  exit.  The  ID,  OD  and  CIRC  cases  all  still  have  high  levels  of  distortion  at  the  exit 
plane.  On  a  side  note,  it  would  be  very  interesting  to  add  the  isolator  section  to  the 
analysis  and  back  pressure  the  system  to  see  how  much  the  inflow  distortion  affects  the 
isolator’s  capability. 


OD  Distortion 

The  OD  distortion  case  started  similarly  to  the  no  distortion  case.  This  was  expected 
since  the  optimization  method  used  was  not  gradient  based  and  the  number  of 
independent  variables  was  large.  It  is,  however,  counter  intuitive  that  out  of  49  trials, 
only  one  would  have  greater  total  pressure  loss  than  the  baseline.  This  seems  to  imply 
that  a  lofted  surface  is  a  very  poor  method  of  generating  a  shape  transition  for  a  super¬ 
sonic  duct. 


1  3  5  7  9  11  13  15  17  19  21  23  25  27  29  31  33  35  37  39  41  43  45  47 


Iteration 

Figure  28,  Control  Point  Locations  and  Resulting  Total  Pressure  Loss  for  Each  Iteration 
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Run  29  showed  the  greatest  total  pressure  benefit,  this  simulation  is  detailed  below. 

The  shape  transition  surface,  compared  to 
the  lofted  surface,  is  shown  in  Figure  29. 
Since  the  surface  is  not  symmetric,  it  is 
probably  not  a  design  that  would  be 
considered.  In  fact,  when  using  this  tool  to 
develop  components  for  manufacture, 
manufacturing  rules  such  as 
maximum/minimum  corner  radii  and/of 
maximum  change  in  surface  and  desired 
symmetry  will  be  input  via  problem  set-up 
and/or  constraints  in  the  optimization 
process. 


Figure  29,  Comparison  of  Baseline  Surface  and 
the  Surface  of  Iteration  29. 


As  can  be  seen  in  Figure  30,  the  CFD 
simulation  was  run  for  2700  iterations. 
The  residual  dropped  approximately 
five  orders  of  magnitude  and  the  mass 
flow  error  was  steady  at  just  about  zero 
percent  error.  The  total  pressure  loss 
calculation  was  also  steady  for  the  last 
400-500  iterations 

Figure  3 1  shows  the  total  pressure, 
static  density  and  Mach  number 
profiles  for  the  OD  distortion  case. 
Note  that  the  Mach  number  profile  at 
the  exit  plane  is  greater  than  Mach  1 .2 
everywhere,  ensuring  the  exit 
boundary  condition  is  well  posed. 


Figure  30,  Convergence  and  FOM  History  for 
Iteration  29  of  the  Optimization  Using  OD  Distortion 
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Frame  001  |  03  Feb  200G  |  Plot3D  DataSet 


Frame  001  03  Feb  2006  Plot3D  DataSet 


Figure  31,  Total  Pressure,  Static  Density  and  Mach  Number  Profiles  for  Iteration  29  of  the  OD 

Distortion  Optimization 
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ID  Distortion 


The  ID  distortion  case  also  started  similarly  to  the  no  distortion  case.  The  ID  case  was 
run  for  55  iterations  and  showed  a  large  improvement  of  over  15%. 


Y 


I  nte  ration 


Figure  32,  Control  Point  Location  and  Relative  Total  Pressure  Loss  of  the  ID  Distortion 

Optimization 


Upon  inspection  of  the  solutions,  many  of  the  best  performers  had  a  separated  flow 

region  at  the  exit  plane,  which  is  not  a  valid 
date  point.  Evaluating  each  iteration  in  order  of 
highest  to  lowest  FOM,  revealed  the  best 
performer  that  had  a  valid  solution  was 
iteration  number  28,  a  which  had  7.5%  gain  in 
total  pressure.  The  surface  for  this  iteration  is 
shown  in  Figure  33.  The  convergence  history 
of  the  simulation  is  shown  in  Figure  34. 

As  with  the  other  cases,  much  further 
refinement  is  required  for  a  design-quality 
solution 


Figure  33,  Comparison  of  Lofted  and 
Optimized  Surface  for  the  ID  Distortion  Case 
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Figure  34,  Convergence  History  for  Iteration  28  Analysis 


Details  of  the  analysis  are  shown  in  Figure  35  below.  These  show  the  total  pressure, 
static  density  and  Mach  number  profiles  for  iteration  28. 
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Frame  001  |  03  Feb  2006  |  Plot30  DataSet 
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Figure  35,  Total  Pressure,  Static  Density  and  Mach  Number  Profiles  for  Iteration  28  of  the  ID 

Distortion  Optimization 
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Circumferential  Distortion 

Unfortunately,  time  ran  out  before  results  for  the  circumferential  optimization  analysis 
were  available. 


CONCLUSION  /  LESSONS  LEARNED 

An  approach  to  an  integrated  design  optimization  and  engineering  analysis  tool  has  been 
demonstrated.  This  tool  leverages  the  significant  work  required  to  set-up  a  detailed 
numerical  analysis.  The  additional  work  required  to  execute  the  optimization  includes 
formally  defining  the  FOMs,  setting  up  the  DAKOTA  input  file  and  possibly  re-defining 
the  geometry  and  topology  for  parametric  grid  generation.  Setting  up  the  DAKOTA 
input  file  is  a  straight  forward  task.  Since  the  process  requires  a  formal  definition  of  the 
FOMs,  the  system  documents  itself  and  is  very  repeatable.  Including  grid  generation  in 
the  loop  requires  some  additional  effort,  however,  the  potential  gains  in  component 
performance  and  system  operability  are  significant. 

An  additional  benefit  of  the  system  is  that  it  can  be  used  to  automate  performance  map 
generation.  The  same  iterator  that  is  required  by  the  optimizer,  in  this  case  DAKOTA, 
can  be  used  to  create  a  performance  map  with  little  additional  work.  The  engineer  is 
relieved  of  the  repetitive  tasks  of  input  file  creation,  job  submission,  etc.  Rather,  he  can 
concentrate  on  the  product,  not  the  process. 

Optimization  Techniques 

Of  the  two  main  types  of  optimization  schemes,  the  gradient  based  methods  were  more 
robust  because  they  only  make  small  changes  to  the  geometry,  which  is  easier  for  the 
topology  to  handle.  The  two  main  drawbacks  to  running  these  types  of  schemes  are  that 
sometime  large  initial  perturbations  must  be  made  to  avoid  the  numerical  noise  and  the 
schemes  find  a  local,  rather  than  a  global  optimum. 

The  non-gradient  based  schemes,  designed  to  find  a  global  solution,  sample  the  entire 
design  space.  Some  do  so  more  aggressively  than  others  and  require  a  more  robust 
topology  be  defined. 

The  preferred  method  of  zeroing  in  on  the  optimum  design  depends  on  the  starting  point 
and  design  space.  If  it  is  early  in  the  design  and  the  design  space  is  large,  it  may  be 
prudent  to  start  with  a  lower  fidelity  model  and  sample  the  entire  design  space  with  a 
sparse  number  of  iterations.  Once  the  non-gradient  based  optimization  is  in  the  ball  park, 
switch  over  to  a  gradient  based  technique  and  run  with  a  higher  fidelity  model. 

Lots  of  Data 

The  main  hurdle  to  integrating  this  tool  into  the  industrial  design  process  is  in  handling 
the  enormous  amounts  of  data  generated.  For  our  shape  transition  case  where  every 
effort  was  made  to  keep  the  simulation  size  down,  generated  over  80  gigabytes  of  data! 
An  automated  method  of  checking  solutions  for  convergence  and  accuracy  is  required. 
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This  could  mean  generating  specialized  scripts  to  interact  with  individual  packages,  or 
potentially  to  use  the  CGNS  standard  as  a  more  general  means  of  communication. 

Finally,  some  manner  of  ensuring  that  the  simulation  is  feeding  the  optimizer  valid  data  is 
required.  This  can  be  done  a  variety  of  different  ways  and  no  one  way  will  be  the  answer 
for  all  cases.  For  instance,  one  case  may  require  restricting  the  computation  domain, 
another  may  be  done  completely  by  post  processing  the  results  while  yet  another  way 
may  involve  tweaking  the  analytical  code  itself.  This  is  where  the  expertise  of  the  users 
will  be  required  as  they  apply  the  tool  to  their  specific  area  of  interest. 
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APPENDICES 
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Appendix  1.A,  DAKOTA  Input  File  for  Fuel  Injector  Case 


#  1st  run  with  DAKOTA  and  Vulcan 

#  on  the  cluster  . . . 

#  gradient-based  unconstrained  optimization 


variables , 

\ 

continuous_design  =  3 

\ 

cdv_descriptor 

'ul'  1 wl 

'  '  expl ' 

\ 

cdv  initial  point 

20  20 

2 

\ 

cdv  lower  bounds 

10  10 

2 

\ 

c  dv_upp  e  r_b  ound  s 

40  40 

10 

interface. 

\ 

application  system. 

\ 

asynchronous 

\ 

evaluation  concurrency  =  1 

\ 

analysis_driver  = 

' vulcan 

driver ' 

\ 

parameters  file  = 

' params . 

in' 

\ 

results_file  = 

' results 

.  out ' 

\ 

f ile_tag 

\ 

file  save 


responses , 

\ 

num  objective  functions  =  1 

\ 

no_gradients 

\ 

no_hessians 

method. 

\ 

#  dot_bfgs 

\ 

sgopt  pattern  search 

\ 

solution_accuracy  =  1.0e-4 

\ 

initial_delta  =0.5  \ 

threshold_delta  =  .0001  \ 

max_f unction_evaluations  =50  \ 

exploratory_moves  best_all  \ 

contraction_f actor  =0.75  \ 

output  quiet 


strategy, 

single_method 
#  graphics 

tabular_graphics_data 


\ 

\ 

\ 
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Appendix  1.B,  VULCAN  Input  File 


i £*********************************************************************£  i  o  .  0 
i £*********************************************************************£  i  o  .  0 

■$****  shaped  Transition  Duct  ***$'  o.O 

i £*********************************************************************£  i  o  .  0 
i £*********************************************************************£  i  o  .  0 
i  $****************  Begining  of  general  control  data  *******************$'  o.O 

'$ -  Parallel  processing  control  data  - $'  0.0 

8.0  (No.  of  cpus  to  use) 

1.0  (Message  passing  strategy:  0=stnd. ,  l=buffered) 

0.0  (Load  balancing  algorithm:  0=stnd.,  l=pmetis,  2=kmetis) 

Geometric  model  type  - $'  0.0 

1.0  (twod,  axisym,  threed) 

Grid  file  data - $'  0.0 

3.0  (l=s.b.form,  2=s .b .unform. ,  3=m.b.form.,  4=m.b.  unform) 

0.0  ( 0=plot3d- >3d  ;  plot2d- >2d/axi ,  l=plot3d- >all ) 


'  PROCESSORS ' 
'MESSAGE  MODE' 

'LOAD  BALANCE  MODE' 

I$ - 

'  THREED ' 

'$ - 

'GRID  FORMAT' 

'GRID' 


0 . 0 


'  baseline_8blk .p3d ' 

'GRID  SCALING  FACTOR'  0.0254  (Converts  grid  units  to  meters) 

'$ - Restart  file  data - 

'  RESTART  OUT '  0.0 

'  Restart_f iles/baseline_8blk_rlx3d . restart ' 

'RESTART  OUT  INTERVAL'  100.0 

'$ - Output  control  data - $'  0.0 

0.0  (0=None,  l=wall  f unct . ,  2=temp.  limit,  3=dq  limit,  4=all 
4.0  (l=s.b.frm.,  2=s .b .unf rm. ,  3=m.b.frm.,  4=m.b .unf rm. ) 

0.0  (Write  32  bit  unformatted  PLOT3D  files) 

0.0  (Create  PLOT3D  files  using  data  averaged  to  the  nodes) 
6.0  (Create  PLOT3D  function  file  containing  variables  below) 

,  'PRESSURE',  'TEMPERATURE',  'MACH  NO.',  'EDDY  VIS.  RATIO' 

Gas  thermo,  diffusion,  and  reaction  model  data  - $'  0.0 

0.0  (0=const.  gamma,  l=mix  therm  perfect,  2=n/a) 

0.0  (Solve  Navier-Stokes  equation  using  global  algor.) 

1.0  (n/a=power  law,  l=Sutherlands  law) 

Free  stream  gas  angle  data - $' 

0.0  ( 0= ALPHA  in  xy  plane,  1= ALPHA  in  xz  plane) 

0.0  (Angle  of  attack  measured  C.C.W  in  degrees) 

0.0  (Angle  of  yaw  measured  C.C.W  in  degrees) 

Force  and  Moment  integration  control  data  - $' 


'WARNING  MESSAGES' 

'PLOT  ON' 

'32  BIT  BINARY' 

'PLOT  NODES' 

'PLOT  FUNCTION' 

'DENSITY',  'VELOCITY 

'$ - 

'GAS/THERMO  MODEL 
'GLOBAL  VISCOUS' 

'VISCOSITY  MODEL' 

'$ - 

'ANGLE  REF.  FRAME 
'ALPHA' 

' BETA ' 

'$ - 

'INTEGRATION  REF.  LENGTH 
coef f ' s) 

'INTEGRATION  REF.  AREA' 
coef f ' s) 

' INTEGRATION  X  SCALE  FACTOR 
moment  coeff's) 

'INTEGRATION  Y  SCALE  FACTOR 
moment  coeff's) 

' INTEGRATION  Z  SCALE  FACTOR 
moment  coeff's) 

'MOMENT  REF.  X' 

'MOMENT  REF.  Y' 

'MOMENT  REF.  Z' 

' INTEGRATION  REF .  PRESSURE ' 
'INCLUDE  SLIP  WALLS' 


0.0 


0.0 


1.0  (reference  length  for  inegrated  force  and  moment 

1.0  (reference  area  for  inegrated  force  and  moment 

1.0  (X  component  scale  factor  for  inegrated  force  and 

1.0  (Y  component  scale  factor  for  inegrated  force  and 

1.0  (Z  component  scale  factor  for  inegrated  force  and 

0.0  (X  coordinate  of  datum  for  moment  integration) 

0.0  (Y  coordinate  of  datum  for  moment  integration) 

0.0  (Z  coordinate  of  datum  for  moment  integration) 

-1.0  (Integration  ref.  pressure,  Pascals) 

0.0  (Include  all  slip  wall  b.c.s  in  the  integration) 


Figures  of  Merit  computation  control  data 


'COMPUTE  TOTAL  PRESSURE  LOSS 

'$ - 

'NONDIM' 

'MACH  NO. ' 

'  GAMMA ' 

'  STATIC  TEMP.  ' 

'GAS  CONSTANT' 

'STATIC  PRESS.' 

'UNIT  REYNOLDS  NO. ' 
'REFERENCE  LENGTH' 
'SUTHERLANDS  LAW  SO' 

'  SUTHERLANDS  LAW  TO ' 
'SUTHERLANDS  LAW  MU0 
'LAM.  PRANDTL  NO. ' 

'  TURB .  PRANDTL  NO .  ' 

'$ - 

'TURB.  MODEL' 


1.0  (Compute  the  total  pressure  loss) 

Reference  condtion  data  - 

( 0=non . dimen .  , 


1 . 0 
2.5 
1.4 
300 . 0 
287.0 
50000.0 
1 . 0 
1.0 

110 . 555556 
273 . 111111 
0 . 1716E- 04 
0 . 72 
'  0 . 90 

Turbulence  model  data 

0.0 


l=dimen.  static,  2=dimen. 


0 . 0 

-$'  0.0 
total ) 


0.0 


'K-OMEGA'  (LAMINAR,  K-EPSILON,  K-OMEGA,  LOW  RE  K-OMEGA,  MENTER,  MENTER-SST) 

'TURB.  INTENSITY'  0.01 

'TURB.  VISC.  RATIO'  0.10 

'BOUSSINESQ  REY.  STRESS'  0.0 

'DURBIN  REALIZABILITY'  1.0 

'NO  2/3  RHOK  IN  REY.  STRESS'  0.0 

'INITIAL  BOUNDARY  LAYER  THICKNESS'  0.010 


34 


AF  SBIR  I  -  FA8650-05-M-2594 


I$ - 

'  NSTAGE ' 

0.333333333333, 

I$ - 

'  FLOWBCS ' 

'  CUTBCS ' 

'  PATCHBCS ' 

'  BLOCKS ' 

'BLOCK  CONFIG. ' 


-  Runge-Kutta  scheme  coefficients  - $' 

3.0  (no.  of  Runge-Kutta  Stages) 

0.5,  1.0 

-  Boundary  and  cut  control  - $' 

22.0  (no.  of  boundary  conditions  to  be  specified) 
13.0  (no.  of  C(0)  cut  conectivity  conditions) 

0.0  (no.  of  Non-C(0)  cut  conectivity  conditions) 


8 . 0 
1 . 0 


(no.  of  blocks) 

(no.  of  lines  of  block  configurations  input) 


'N' 


1 . 0 


0  'N' 

'REGION  CONFIG. ' 

'$****  Region  1 
'  LDFSS  KAPPA 
3,  3,  3, 

'  FMGLVLS  NITSCG1  NITSFG 
2,  100,  500, 


0 . 0 


0 . 0 


'  BLK  I -VISCS.  J-VISCS.  K-VISCS.  TURBULENCE  PLOT  SOLVER  REGION' 

'N'  'N'  ' Y '  'E/A'  1 

(no.  of  regions  the  blocks  are  grouped  into) 
control  input  **************************************$' 
LIMITER  LIM.-COEF.  ENTRP (U)  ENTRP (U+a) ' 

2,  2,  2,  2.0,  2.0,  2.0,  0.0,  0.0,  0.0,  0.0,  0.0,  0.0 

#1ST-0RD. -C.G. /ITER.  RES. ; REL . ,ABS. ' 

-2,  -99.0,  -99.0 


0 . 0 


'M.G. -CYCLE  #C.-G.  DQ-SMOOTH  DQ-CORR.  DAMP-MEAN  DAMP-TURB.' 

'I',  1,  0.10,  -0.25,  0.50,  0.25 

'TURB.  CONVEC. -ORDER  DT-RATIO  NON-EQUIL.  POINT-IMP.  COMP. MODEL  C . G . WALL-B . C . 1 

'2ND',  1.0,  25.0,  ' Y ' ,  ' Y ' ,  'WMF' 

'SCHEME  TIME-STEP  IT-STATS  CFLMIN  ADPCFL  #CFL-VAL  VISC-DT  IMP-BC  REG-REST.' 


' R3D '  ,  'LOCAL'  ,  10,  0.5,  '  i 

'SWEEP-DIR  NS TART  NMOD  KITER' 

0,  1,  0,  2 
1,  100,  101,  200 
0.10,  400.0,  0.10,  400.0 


4  , 


i i*******************  End  of  general  control  data  *********************1 1  0.0 


BC  NAME 

BLK 

FACE 

PLACE 

DIREC1 

BEGIN 

END 

DIREC2 

BEGIN 

END 

IN-ORDER 

BC  TYPE 

SUP -OUT. ' 

1 

'  K ' 

'MIN' 

'  I  ' 

'MIN' 

'MAX' 

'  J' 

'MIN' 

'MAX' 

0 

' EXTRAP ' 

ADB-WALL ' 

1 

'  I  ' 

'MAX' 

'  J' 

'MIN' 

'MAX' 

'  K ' 

'MIN' 

'MAX' 

0 

' SWALL ' 

SUP- INF. ' 

1 

'  K' 

'MAX' 

'  I  ' 

'MIN' 

'MAX' 

'  J' 

'MIN' 

'MAX' 

0 

' AREFFIX 

ADB-WALL' 

2 

'  I  ' 

'MIN' 

'  J' 

'MIN' 

'MAX' 

'  K ' 

'MIN' 

'MAX' 

0 

' SWALL ' 

SUP -OUT. ' 

2 

'  K ' 

'MIN' 

'  I  ' 

'MIN' 

'MAX' 

'  J' 

'MIN' 

'MAX' 

0 

' EXTRAP ' 

SUP- INF. ' 

2 

'  K' 

'MAX' 

'  I  ' 

'MIN' 

'MAX' 

'  J' 

'MIN' 

'MAX' 

0 

'AREFFIX 

ADB-WALL' 

3 

'  I  ' 

'MIN' 

'  J' 

'MIN' 

'MAX' 

'  K ' 

'MIN' 

'MAX' 

0 

' SWALL ' 

SUP -OUT. ' 

3 

'  K ' 

'MIN' 

'  I  ' 

'MIN' 

'MAX' 

'  J' 

'MIN' 

'MAX' 

0 

' EXTRAP ' 

SUP- INF. ' 

3 

'  K' 

'MAX' 

'  I  ' 

'MIN' 

'MAX' 

'  J' 

'MIN' 

'MAX' 

0 

'AREFFIX 

SUP -OUT. ' 

4 

'  K ' 

'MIN' 

'  I  ' 

'MIN' 

'MAX' 

'  J' 

'MIN' 

'MAX' 

0 

' EXTRAP ' 

ADB-WALL' 

4 

'  I  ' 

'MAX' 

'  J' 

'MIN' 

'MAX' 

'  K ' 

'MIN' 

'MAX' 

0 

' SWALL ' 

SUP- INF. ' 

4 

'  K' 

'MAX' 

'  I  ' 

'MIN' 

'MAX' 

'  J' 

'MIN' 

'MAX' 

0 

'AREFFIX 

SUP -OUT. ' 

5 

'  K ' 

'MIN' 

'  I  ' 

'MIN' 

'MAX' 

'  J' 

'MIN' 

'MAX' 

0 

' EXTRAP ' 

ADB-WALL' 

5 

'  I  ' 

'MAX' 

'  J' 

'MIN' 

'MAX' 

'  K ' 

'MIN' 

'MAX' 

0 

' SWALL ' 

SUP- INF. ' 

5 

'  K' 

'MAX' 

'  I  ' 

'MIN' 

'MAX' 

'  J' 

'MIN' 

'MAX' 

0 

'AREFFIX 

SUP -OUT. ' 

6 

'  K ' 

'MIN' 

'  I  ' 

'MIN' 

'MAX' 

'  J' 

'MIN' 

'MAX' 

0 

' EXTRAP ' 

SUP- INF. ' 

6 

'  K ' 

'MAX' 

'  I  ' 

'MIN' 

'MAX' 

'  J' 

'MIN' 

'MAX' 

0 

'AREFFIX 

ADB-WALL ' 

7 

'  I  ' 

'MIN' 

'  J' 

'MIN' 

'MAX' 

'  K' 

'MIN' 

'MAX' 

0 

' SWALL ' 

SUP -OUT. ' 

7 

'  K ' 

'MIN' 

'  I  ' 

'MIN' 

'MAX' 

'  J' 

'MIN' 

'MAX' 

0 

' EXTRAP ' 

SUP- INF. ' 

7 

'  K ' 

'MAX' 

'  I  ' 

'MIN' 

'MAX' 

'  J' 

'MIN' 

'MAX' 

0 

'AREFFIX 

SUP -OUT. ' 

8 

'  K' 

'MIN' 

'  I  ' 

'MIN' 

'MAX' 

'  J' 

'MIN' 

'MAX' 

0 

' EXTRAP ' 

SUP- INF. ' 

8 

'  K ' 

'MAX' 

'  I  ' 

'MIN' 

'MAX' 

'  J' 

'MIN' 

'MAX' 

0 

'AREFFIX 

CUT  NAME 

BLK 

FACE 

PLACE 

DIREC1 

BEGIN 

END 

DIREC2 

BEGIN 

END 

IN-ORDER' 

CUT  1  ' 

3 

'  J ' 

'MAX' 

'  K' 

'MIN' 

'MAX' 

'  I  ' 

'MIN' 

'MAX' 

0 

CUT  1' 

1 

'  J ' 

'MAX' 

'  K ' 

'MIN' 

'MAX' 

'  I  ' 

'MAX' 

'MIN' 

0 

CUT  2  ' 

4 

'  J' 

'MIN' 

'  K' 

'MIN' 

'MAX' 

'  I  ' 

'MIN' 

'MAX' 

0 

CUT  2  ' 

3 

'  J' 

'MIN' 

'  K' 

'MIN' 

'MAX' 

'  I  ' 

'MAX' 

'MIN' 

0 

CUT  3  ' 

4 

'  J' 

'MAX' 

'  K ' 

'MIN' 

'MAX' 

'  I  ' 

'MIN' 

'MAX' 

0 

CUT  3  ' 

2 

'  J' 

'MAX' 

'  K' 

'MIN' 

'MAX' 

'  I  ' 

'MAX' 

'MIN' 

0 

CUT  4  ' 

5 

'  J' 

'MAX' 

'  K' 

'MIN' 

'MAX' 

'  I  ' 

'MIN' 

'MAX' 

0 

CUT  4  ' 

1 

'  J' 

'MIN' 

'  K ' 

'MIN' 

'MAX' 

'  I  ' 

'MIN' 

'MAX' 

0 

CUT  5  ' 

6 

'  I  ' 

'MIN' 

'  J' 

'MIN' 

'MAX' 

'  K' 

'MIN' 

'MAX' 

0 

CUT  5  ' 

3 

'  I  ' 

'MAX' 

'  J' 

'MIN' 

'MAX' 

'  K' 

'MIN' 

'MAX' 

0 

CUT  6  ' 

6 

'  I  ' 

'MAX' 

'  J' 

'MIN' 

'MAX' 

'  K ' 

'MIN' 

'MAX' 

0 

CUT  6  ' 

5 

'  I  ' 

'MIN' 

'  J' 

'MIN' 

'MAX' 

'  K' 

'MIN' 

'MAX' 

0 

CUT  7  ' 

6 

'  J' 

'MAX' 

'  K' 

'MIN' 

'MAX' 

'  I  ' 

'MIN' 

'MAX' 

0 

CUT  7' 

1 

'  I  ' 

'MIN' 

'  K ' 

'MIN' 

'MAX' 

'  J' 

'MAX' 

'MIN' 

0 

CUT  8  ' 

7 

'  J' 

'MIN' 

'  K' 

'MIN' 

'MAX' 

'  I  ' 

'MIN' 

'MAX' 

0 

CUT  8  ' 

5 

'  J' 

'MIN' 

'  K' 

'MIN' 

'MAX' 

'  I  ' 

'MAX' 

'MIN' 

0 

CUT  9' 

7 

'  J' 

'MAX' 

'  K ' 

'MIN' 

'MAX' 

'  I  ' 

'MIN' 

'MAX' 

0 

CUT  9' 

2 

'  J' 

'MIN' 

'  K' 

'MIN' 

'MAX' 

'  I  ' 

'MIN' 

'MAX' 

0 

CUT  10' 

8 

'  I  ' 

'MIN' 

'  J' 

'MIN' 

'MAX' 

'  K' 

'MIN' 

'MAX' 

0 

CUT  10' 

7 

'  I  ' 

'MAX' 

'  J' 

'MIN' 

'MAX' 

'  K ' 

'MIN' 

'MAX' 

0 

CUT  11' 

8 

'  J' 

'MIN' 

'  K' 

'MIN' 

'MAX' 

'  I  ' 

'MIN' 

'MAX' 

0 

CUT  11' 

6 

'  J' 

'MIN' 

'  K' 

'MIN' 

'MAX' 

'  I  ' 

'MAX' 

'MIN' 

0 

CUT  12 ' 

8 

'  I  ' 

'MAX' 

'  J' 

'MIN' 

'MAX' 

'  K ' 

'MIN' 

'MAX' 

0 

CUT  12 ' 

4 

'  I  ' 

'MIN' 

'  J' 

'MIN' 

'MAX' 

'  K ' 

'MIN' 

'MAX' 

0 

CUT  13 ' 

8 

'  J' 

'MAX' 

'  K' 

'MIN' 

'MAX' 

'  I  ' 

'MIN' 

'MAX' 

0 

CUT  13 ' 

2 

'  I  ' 

'MAX' 

'  K ' 

'MIN' 

'MAX' 

'  J' 

'MIN' 

'MAX' 

0 
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Appendix  1.C,  Driver  Script  for  Fuel  Injector  Analysis 

#!/bin/csh  -f 

#  Sample  simulator  to  Dakota  system  call  script 

#  See  User  Manual  for  instructions 

# 

#  bvbw  10/24/01 

# 

#  modified  for  use  with  Vulcan 

# 


Driver  script  written  in  csh 
Plans  to  convert  to  PERL 


#  $argv[l]  is  params . in . ( fn_eval_num)  FROM  Dakota 

#  $argv[2]  is  results . out .( fn_eval_num)  returned  to  Dakota 


# - 

#  Set  up  working  directory 

#  - 

set  num  =  'echo  $argv[l]  |  cut  -c  11-' 


Get  the  unique  number  for  this  run 


cp  -r  template_dir  workdir.$num 
mv  $argv[l]  workdir.$num 
cd  workdir.$num 


>  Copy  the  template,  or  baseline  directory,  to 
the  working  directory 


# - 

#  PRE-PROCESSING 

#  - 

#  Use  the  following  line  if  SNL’s  APREPRO  utility  is  used  instead 

#  of  transfer_perl . 

#  ../aprepro  -c  -g  --nowarning  ros. template  ros.in 


../dprepro  $argv[l]  template,  fra  _az.fra 

../dprepro  $argv[l]  cap_surf_inp . template  cap_surf.inp  - 

../dprepro  $argv[l]  vulcan . template  vulcan.inp 
# - 

#  ANALYSIS 

#  - 

#  Grid  Generation 

#  1st  generate  the  capsurface  _ _ _ 

. . /capSurface  cap_surf.inp  - 

#  now  generate  the  new  grid 

Ggrid  _az.fra  -D  2  >  _az.out  - 

mrgb  blk.tmp  -or  >  mrgb.out 

chfmt  blk.tmp. tmp  -f  p3d  -D  >  chfmt.out  _ 

#  RUN  VULCAN 

set  gscript  =  qv_sgopt_pga$num 


Use  DPREPRO  utility  to  read  PARAMS.IN.X 
file  (generated  by  DAKOTA),  parse  data 
then  search  and  replace  template  files  with 
data 


Generate  the  cap  surface  for  the  fuel  injector 
tube 

Generate  the  grid  -  schedule  (_az.sch) 
file  copied  from  template  directory 
Merge  the  blocks  in  the  grid  -  merge 
schedule  can  be  in  template  directory 


cp  qv_fi  $qscript 


#set  qnum  -  qSub  $qscriPt  ,  cut  -c  -a-  - -  Submit  VULCAN  job  to  PBS  que 

qsub  $qscript  |  cut  -c  -3  >  QNUM  - 

set  qnum  =  'cat  QNUM' 


#  now  wait  until  the  job  has  finished  by 

#  checking  for  the  existance  of  the  $qscript . o$qnum  file 


while  (1) 
sleep  10 

if  (-f  $qscript .o$qnum)  then 
break 
endif 
end 


Loop  until  output  file  exists,  indicating  the 
VULCAN  has  completed  or  erred  out 


# - 

#  POST-PROCESSING 

#  - 

#  for  now  use  tail  and  hard  code  position  in  the  file  - 

#  plan  to  make  more  general  later 

tail  -n  1  vulcan . if am_his . tec_l  |  cut  -c  140-  >!  $argv[2] 


Read  the  VULCAN  FOM  file  and  pipe  the 
appropriate  value  into  the  RESULTS.OUT.X 
file,  argument  2  into  the  script 


#  NOTE:  moving  $argv[2]  at  the  end  of  the  script  avoids  any 

#  problems  with  read  race  conditions. 

mv  $argv[2]  ../.  _ 

#  - 

#  Clean 

#  - 

cd  .  . 


Move  the  output  file  up  1  directory 

CD  up  1  directory  to  start  the  next  simulation 
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